> > ------- =_aaaaaaaaaa0 > > Content-Type: text/x-pgp; charset="us-ascii" > > Content-ID: <22906.791264012.1@merde.dis.org> > > Content-Description: Pgp signed cleartext > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > > > Here is a program that does some of what der Mouse's device > > driver does but runs as program that edits /dev/kmem to disable > > the device /dev/vd. > > > > I did what can to bullet proof the code so that it does not stomp on > > the wrong device driver. > > > > Written and tested under 4.1.3u1 > > > > -Pete > > shipley@dis.org > > > AntiHijacking tool? It disables sun4's kernel ability to modload modules > on fly, thus also disables things like ppp, slip, et al. I won't call it > a solution. There are other (obvious) problems too...the most obvious being get root, alter /etc/rc* and either reboot or wait for it. Unless they store a TripWire DB on a storage device which is removable and can have read-write toggled easily (ie floppy disk) and they use it daily, you're defeated even with these tools. And, I might add, there is little to be done to stop it, it would seem. If you've got a SunOS4.x machine, want to run Sun stuff, and are desperately worried about its security, you'll gain a *lot* more by putting NetBSD(current)-sparc on it. You'll also save yourself a lot of time trying out these other solutions. The only thing NetBSD doesn't offer is a way to defeat guessing the ISN, but the only safe way I would consider changing this is to have it increase (at all stages) by a random amount at regular intervals rather than once per packet at any stage. darren p.s. yes, a reboot is obvious, and even if you have security-mode full, you may not notice if they wait for you to reboot or they cause a panic through some kernel bug. And by this time it is too late. p.p.s unless upon rebooting you check *every* binary you execute for changes since the last (something like running TripWire *very* early in /etc/rc*) you may or may not know if anything has been changed before you go into multi-user mode. This is getting towards the extreme paranoia end of the spectrum, however. By making all directories and files involved with rebooting restricted to be changed by root (under NetBSD), you stand a chance of being immune to a trojan taking advantage of the boot procedure. Depressed yet, about unix security ?